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ABSTRACT 

The simulated performance characteristics for 
communication between a terrestrial client and a 
LEO satellite server are presented. The client and 
server nodes consist of a TCP/IP over ATM 
configuration. The ATM cells from the client or 
the server are transmitted to a gateway, packaged 
with some header information, and transferred to 
a commercial LEO satellite constellation. These 
cells are then routed through the constellation to 
a gateway on the globe that allows the 
client/server communication to take place. UBR 
(unspecified bit rate) is specified as the quality of 
service (QoS). Various data rates are considered. 

INTRODUCTION 

The motivation for this research arises from the 
desire to maintain continuous TCP connections 
between the NASA terrestrial base, which is the 
client, and the server on a NASA LEO satellite, 
regardless of its position over the globe. Two 
possible resolutions to the problem of global 
coverage can be considered. The first is the 
utilization of a number of GEO satellites. The 
power requirements and launch technology of 
GEO satellites causes them to be very expensive. 
Also, the delay involved in communicating 
across GEO hops is a concern. 

A second, and more recent, alternative is the use 
of an intermediate LEO constellation to provide 
global coverage. LEO satellites do not have the 
power requirements of GEOs, and recent launch 
technologies have allowed LEOs to be 
positioned at a relatively low cost. Since LEOs 


are positioned at a much lower altitude than 
GEOs, much smaller transmission delays and 
atmospheric interference are experienced. 

This paper investigates the use of a commercial 
LEO constellation as an intermediate network 
between a terrestrial client and a LEO satellite 
server. The client at the NASA base in Houston, 
Texas and the server on a NASA LEO satellite 
orbiting the Earth, in the same orbit as the 
Spartan 1, communicate using the satellite 
constellation [1]. The performance of TCP/IP 
over ATM between the client and the server are 
presented. Although current LEO satellite 
constellations are primarily intended for voice 
communications and have a low data rate, our 
intention is to examine them as potential means 
for providing TCP/IP over ATM communication 
between LEO mission satellites and terrestrial 
locations. 

SATELLITE NETWORK 

The constellation consists of 66 LEO satellites. 
These LEOs are capable of inter-satellite 
communication, as well as uplink and downlink 
ability. The frequency used for uplinks is 29.2 
GHz and for downlinks it is 19.5 GHz. The 
satellites communicate with each other at 23.28 
GHz. For all communications, quartemary phase 
shift keying (QPSK) is used as the modulation 
scheme. The satellites are in 6 orbits with 11 
satellites in each orbit. The LEO constellation 
uses 12 gateways positioned globally, according 
to the current Iridium ground facilities [2]. 
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Figure 1 


For the purposes of this simulation, the ground 
stations serve as bridges to and from the LEO 
constellation. The ground station located near 
Phoenix, Arizona is connected to the NASA 
Johnson Space Center in Houston. The overall 
network is shown in Figure 1. The smaller 
circular nodes represent the constellation of 
LEOs. The node represented by the satellite icon 
is the NASA mission LEO. The twelve 
terrestrial gateways are represented by receiver 
dish icons. 

FUNCTIONAL DESCRIPTION 

A brief overview of the flow of information 
between the client and the server is as follows. 

The NASA base located in Houston, Texas 
serves as the client node and generates requests. 
The server resides on a NASA mission LEO 
satellite that is in orbit to collect mission-related 
data and transfers information to the NASA base 
upon request. Both the client and the server 
processes use a TCP/IP over ATM architecture. 
The QoS specified by both the client and the 
server is UBR only [3, 4]. 

The client generates requests, which are 
segmented into ATM cells (after IP segments the 
TCP information into IP datagrams) and 
transferred to the gateway in Arizona via an 
optical link. At that point, the gateway adds a 
few bytes of header information that will allow a 
traversal across the LEO satellite constellatioa 


This information simply marks the source and 
the destination of the cells. The cells are routed 
to the constellation’s gateway that is closest to 
the NASA LEO at that instant The gateway 
receives the cells, removes the header 
information, and transmits the ATM cells up to 
the NASA LEO, where the ATM cells are 
reassembled into IP datagrams. The datagrams 
are then delivered to the TCP layer and on to the 
application. 

The NASA LEO then processes the requests and 
transmits down to the closest constellation 
gateway. The gateway then adds the header 
information and transmits the cells to the LEO 
constellatioa The cells are then routed through 
the network back to the gateway in Arizona. The 
header information is removed, and the ATM 
cells are transferred via the optical link back to 
the NASA base in Houston, Texas. 

The simulation is modeled after a contributed 
model which is packaged with OPNET Modeler 
5.1 [5]. The model, called sat_rte_example, 
illustrates a technique to subject a LEO 
constellation to traffic conditions. Additional 
processes were developed that allowed ATM 
cells to be effectively transmitted over a LEO 
constellation. Also, the routing method for the 
constellation was altered to transfer information 
across the network more efficiently. The result 
was a fully functional TCP/IP over ATM hybrid 
client/server network, which utilized an 
intermediate LEO satellite constellation. 






NODE ARCHITECTURES 

The simulation is based on five types of nodes, 
which are described in this section. 

A. Client Node (NASA BASE) 



The client node consists of a client process over 
a TCP/IP over ATM protocol stack. The client 
process simulates the generation of requests for 
FTP transfers. The client requests 10 file 
transfers per hour, with a 50/50 mix of “get” and 
“put” operations. The average file size is 50,000 
bytes. The QoS specified in this simulation is 
UBR. This QoS will best represent the type of 
traffic that the network will be subjected to. 

B. Server Node (NASA mission LEO satellite) 

The server node has the same architecture as the 
client node. The server process functions over a 
TCP/IP over ATM protocol stack. The server is 
configured to service FTP requests. The layers 
under the server process are exactly the same as 
those of the client node to ensure a virtual link 
between the client application layer and the 
server application layer. 


C. Gateway Nodes (Excluding Arizona) 



In addition to the gateway in Arizona, which is 
connected to the NASA base, there are 11 
gateways that are capable of receiving and 
transmitting information to and from the NASA 
LEO satellite. 

If ATM cells are received from the NASA LEO, 
then the gateways forward the information to the 
“to_base” process. This process finds the 
destination gateway (for these nodes the 
destination will always be the Arizona gateway), 
attaches the source and destination information 
to the ATM cells in the form of a header, and 
forwards them to the “Rte” process. The “Rte” 
process decides how the cells will traverse the 
constellation and then transmits to the 
appropriate LEO satellite. 

Cells from the LEO network take different paths. 
Note that a gateway will only receive cells from 
the LEO network when it is the closest gateway 
to the NASA mission LEO. The cells come into 
the receiver and are forwarded to the 
“conv_down” process. Here the LEO network 
header information is removed, which results in 
the original ATM cell. The ATM cell is then 
sent to the “IRGRN_2NLEO” process, which 
finds the NASA mission LEO and communicates 
with it. 


D. Gateway Node in Arizona 



The gateway located in Arizona contains point- 
to-point and radio transmitters and receivers. If 
ATM cells originate from the NASA base, the 
cells are packaged with source and destination 
header and routing information, and are 
transmitted to the nearest satellite in the LEO 
constellation. Note that these cells will always 





be destined to the gateway nearest to the NASA 
mission LEO. 

If, however, the ATM cells are received from the 
LEO network, the header information is stripped 
and the ATM cells are forwarded to the NASA 
base. 

E. LEO Nodes 
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Figure 5 

The satellite node is based on the contributed 
model, “sat_rte_example”. Although it has the 
same structure, the routing is slightly different 
because it minimizes the number of hops across 
the LEO network. 

The traffic simulation scheme is the same as the 
contributed model. The model applies a user 
specified baseline traffic load for various regions 
over the globe. The LEOs over the regions are 
then subject to this baseline traffic. The LEOs 
receive cells, decide whether the cells are to be 
sent to a gateway or forwarded to the next LEO, 
react according to the region’s traffic condition, 
and then send the cells to the transmitter. 

SIMULATION RESULTS 

The simulation results are based on three 
different scenarios. In Scenario #1, there is no 
upper bound on the rate at which information is 
transferred over the LEO network. In Scenario 
#2, the data rate of the Iridium network (2400 
bps) is used. In Scenario #3, the transfer rate of 
the Globalstar network is used, since it has the 
next higher data rate among LEO constellations, 
with a baseline traffic introduced to the network 
[ 6 ]. 

All simulation results are for 6000 seconds, 
which is enough time for the NASA mission 
LEO to orbit the Earth once. 

A. Scenario #1 (Unlimited bit rate) 

Since there is no upper limit on the rate of 
transfer over the LEO constellation and the 
network is not subject to any outside traffic, the 
transfer rate over the network is optimized. The 
performance of the FTP service over the 
client/server connection can be represented by 


the flow of FTP traffic between the source and 
the destination. 

Figure 6 shows the FTP traffic sent from the 
client application, and Figure 7 shows the FTP 
traffic received at the server in bytes/sec. 



<«o 


Figure 6 
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Figure 7 

As seen from Figures 6 and 7, the FTP traffic 
sent from the client is received intact at the 
server with only minimal delay, indicating that 
the simulation model is valid. 

The delay between the source and destination 
ATM layers can be observed by monitoring the 
flow of UBR cells. Figure 8 depicts the delay 
experienced by the ATM cells from the server to 
the client 
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Figure 8 

The variations in cell delay are due to the 
changing communication paths. Also, the major 
delay points occur when the NASA mission LEO 
is over regions of the Earth that do not contain 
terrestrial gateways. 

The end-to-end delay for TCP segments between 
the peer protocols is shown in Figure 9. This 
delay is for the traffic from the NASA LEO 
server to the NASA client base. 
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Figure 9 

The major delay spike corresponds 
approximately to the point in time when the 
NASA LEO passes over the South Pacific 
Ocean. In this simulation there are no gateways 
located in this region, resulting in this large 
delay. 

Overall, the network performed as expected. 
After the TCP connection was initiated, delays 
were experienced over regions without terrestrial 
gateways. Since there is no other network traffic 
involved and there is no upper limit on the 
transfer rate, the data is transferred between the 
client and the server with little delay in other 
regions. 


B. Scenario #2 (2400 bps) 

This scenario specified an upper bound on the 
transfer data rate over the LEO network that is 
equivalent to that of the Iridium constellation 
(2400 bps). Although there is communication 
between ATM peer processes, the network did 
not allow a TCP connection to be established. 
This is most likely caused by the processing 
delays involved with the changing network 
topology and the TCP/IP over ATM architecture. 
No simulated data is reported for this scenario 
due to the insufficient data rate. 

C. Scenario #3 (9600 bps with network traffic) 

This scenario introduces background traffic 
conditions to tire LEO constellation which 
change relative to the geographic regions of the 
globe. It is probably more representative of 
TCP/IP over ATM connections implemented in 
first-generation LEO satellite constellations. 

Figures 10 and 1 1 show the FTP traffic 
transmitted by the LEO server and received by 
the NASA client base, respectively. In contrast 
to Scenario #1, the data rate limit causes 
significant delay and loss from end to end. 
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Figure 10 
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The UBR cell delay for the ATM layer from the 
LEO server to the terrestrial client is shown in 
Figure 12. 


LEO satellite network, significant delays are 
experienced. 

CONCLUSIONS 

Two conclusions can be drawn from this 
research. First, the data rate of the LEO 
constellation is the most limiting aspect of the 
network. This research determined that a 2400 
bps data rate does not provide sufficient 
bandwith to support the UBR QoS; however, a 
9600 bps transfer rate will just support the UBR 
QoS. Second, a LEO satellite can communicate 
with a terrestrial base, utilizing a LEO 
constellation, with performance characteristics 
that are acceptable given the limitations imposed 
by the network. 
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Figure 12 

The end-to-end delay for TCP traffic between the 
LEO server and the terrestrial client is shown in 
Figure 13. 
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Figure 13 

Due to the 9600 bps data rate, the background 
network traffic, and the changing topology of the 



